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Method and Apparatus for Secure Transmission 
of Data and Applications 

Description 

5 

Field of the Invention 

Hand-held computing devices like personal digital assistants (PDA), snaart phones 
or smaitcards are typically limited in terms of memory, processing power and 
communications bandwidth. Because of these limitations, aggravated by the gen- 

10 erally low data transmission rates between the device and a central application 
provider, e.g, a computer base, such transmissions are rather cumbersome and 
need relatively long times. This applies to any data or program exchange with the 
device, be it the downloading or incrementing of applications or the uploading of 
data. Delays are unavoidable because of both the limited memory in the device 

1 5 and the required security. 

Introduction and Prior Art 

In this description, the present invention will be discussed with specific reference 
to smartcards as typical examples of hand-held computing devices, with the 

20 understanding that the same solution is directly applicable to other portable 

devices with similar properties. Generally, a smartcard is a card similar in physi- 
cal characteristics to common magnetic stripe cards, such as banking or credit 
cards. Additionally, a smartcard typically contains one or several micro- 
processors and also possesses larger amounts of memory than found in magnetic 

25 stripe cards. Consequently a smartcard is a sufficiently powerful device to per- 
form complex applications such as banking or payment, and farther, such applica- 
tions may be securely executed using authentication, encryption and digital 
signatures. Typically, today's smartcards have 2 kB of RAM and 16 kB of ROM, 
and the data transmission rate between the central computer base and the smart- 

30 card is 9600 Baud (B/second), 
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A general computing device, such as a PC or a workstation, stores applications in 
some permanent storage media, such as a hard disk, and then reads an application 
into main memory (RAM) for execution as required. Subject to available 
5 memory^ new applications can be freely added while old applications can be easily 
removed or updated. However for a smartcard, given its limited memory capacity, 
applications are typically loaded into its ROM at the time of fabrication. This 
approach is convenient for the large scale production of smart cards supporting 
one or a few fixed applications. But this approach is less suitable if the set of 
10 applications to be supported is expected to change, or if old applications need to 
be updated, or if the number of cards supporting a given application are not to be 
produced in large quantities, 

A more flexible approach is to design the smartcard so that applications can be 
15 downloaded to the card as required. For example, in the ESPRIT project CAS- 
CADE of the European Union, a smartcard was designed where the pre-installed 
software consists of a small boot kernel, libraries for basic I/O and cryptography, 
and a secure downloading mechanism, where other applications and systems code 
are downloaded securely to a FLASH memory (approximately 16 KB) to the card. 
20 In the Internet publication http://diceMctac,be/crypto/cascade/cascade,html^ this 
approach is described in detail. Since an application may be quite large with 
respect to the amount of RAM or bandwidth available to the smartcard, it is antici- 
pated that an application will be partitioned into code blocks Bl, B2y , Bn and 
each code block will be downloaded in a separate communication to the smart- 
25 card. Also, if an application is to be updated, then only those blocks that have 

been modified need be re-installed on the smartcard. We note that the code blocks 
may represent either application code and/or application data. 
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Using this scheme of code block partitioniag, there are two parameters of special 
interest in evaluating a given solution with respect to downloading and updating 
code blocks: delay requirements and memory requirements. 

5 Delay: The download or updating of code blocks should be "on-the-fly" in the 

sense that blocks which are incorrect due to some error should be detected quickly 
to avoid wasting bandwidth and memory. Assuming that at each time unit a new 
block arrives at the smaitcard during download or update, if now a block Bi 
arrives at time /, but cannot be verified (e.g. by a hash check) until the arrival of 
10 block B(i + d) at time t^d^ then we say that the verification of Bi is delayed for d 
blocks. For a given scheme, we are interested in the maximum delay for block 
verification. We will say that verification is "on-the-fly** if the maximum delay is 
constant or fixed, which will be denoted as 0(1). 

15 Memory Requirements: As code blocks arrive^ they must be stored, and there is 
an amount of additional memory necessary for intermediate calculations to verify 
the received blocks. 

For code download, the time to process n blocks is proportional to n, denoted as 
20 0(n); the memory and block verification time may also be 0(n), A protocol dem- 
onstrates a gain in efficiency if either the memory or verification delay is reduced, 
possibly to 0(log «), or even to 0(1). If n code blocks B1,B2, ... ,Bn are to be 
downloaded, we not only require authentication on each block, but also on the 
blocks as a whole, so as to authenticate the application represented by all the code 
25 blocks collectively. 

One approach to establishing the authenticity of the application is to create depen- 
dencies between the blocks via cryptographic hashing, and cryptographically sign- 
ing a hash value that depends on all blocks. 
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For a different problem, Merkle described an interesting approach in "A Cer- 
tified Digital Signature" in Advances in Cryptology, CRYPTO 89, LNCS voL 
218, G. Brassard ed., Springer-Verlag, pages 218-238* 1989, later patented in 
Merkle US patent 4 309 569, The authentication tree disclosed by Merkle is 
intended for authenticating a large number of public values with a single signa- 
ture, such as a collection of public key certificates in a database, but this so-to- 
speak static approach does not address the specific problems and dynamics of 
secure downloading data or code, particularly onto a device with limited memory 
capacity and/or limited processing power, e.g. a smartcard. 

On the other hand, the CASCADE approach mentioned above does not use an 
authentication tree. Instead, it employs a "linear" hash chain, such that Bi 
depends on B(i-tl), B(i+1) then depends on B(i+2) and so on, which implies that a 
large part of this chain must be recomputed if one block is updated. Thus, though 
the CASCADE approach has an advantage over the prior art methods since it is 
not necessary to recompute or retransmit all code blocks, it is stUl a rather lengthy 
and cumbersome process. 

A specific problem related to the secure download/update of applications on a 
portable device is that of signing digital data streams, sometimes referred to as 
digital flows. Several applications, such as video on-demand distribution or stock 
market feeds, require large amounts of data to be delivered from a set of data 
sources to a set of data receivers. Usually the data will be encrypted, but it is also 
required that the receivers be able to verify the source from which the data orgi- 
nated, such as a video server or an agent of the stock market. Since the data 
stream is typically divided into packets, each packet could be signed individually 
for proof-of-origin, but this would place a high computational burden on both the 
sender and all receivers. For real-time services, such as video on-demand, most 
receivers will not have enough processing power to perform a signature 
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verification for every packet received without adversely effecting the quality of 
the service. 

There are various approaches to solving the stream signature problem, but most 
5 are based on the idea of hashing together n data packets and then producing one 
signature for all these packets. Thus the "cosf * of one signature generation/verifi- 
cation is spread over n data packets, relieving the work at both the sender and the 
receivers* This general approach is similar to the one outlined for the present 
application download/update problem, but there are several important differences 

1 0 that make the solutions to the two problems different. First, for digital streams 

there is really no notion of updating data,, especially for real-time services, as data 
that is sent is either received or lost due to some error, and there is no time to 
request that the data be sent again. Second, since data streams may be transmitted 
over large networks with widely varying qualities of service, one must cope with 

15 the loss of packets. This implies that a signature computed over n packets may be 
unverifiable if one of the packets is lost in transmission. Generally in the applica- 
tion download/update scenario, packet or code block loss is not a serious problem, 
and the protocol need not be specifically tailored to accomodate errors in trans- 
mission. A related issue is that of packets being reordered during transmission, 

20 which is a common characteristic of general packet-switched networks, but not for 
the here anticipated scenario for application download/update. 

An interesting solution for signing digital data streams present Wong and Lam in 
"Digital signatures for flows and multicasts", published in the IEEE/ACM Trans- 

25 actions on Networking, 7(4), pp. 502-513, August 1999. In the Wong-Lam solu- 
tion, the stream is broken into « = 2*^ packets Pi, P2, Pi^ Pn ttiat are 
collected into a transmission group TG. The packets of TG are then arranged to 
be the leaves of a Merkie authentication tree T, and the hash of the tree is com- 
puted and signed by the sender to produce Sign(TG). When TG is transmitted, 

30 each packet Pi is sent with the sequence of hash values that were used to form the 
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path in the hash tree from the leaf representing Jf^ to the root of the authentication 
tree T. The signature Sign(TG) on the authentication tree T is also sent with each 
packet and packet hash path. This permits each packet Pi to be verified as it is 
received, even though other packets in the TG of Pi may have been lost or reor- 
5 dered. To verify a given packet Pi, the receiver is typically required to recompute 
the path in the authentication tree from the leaf representing Pi to the root of T, 
and then verify Sign(TG) based on the computed root hash. The full hash path 
from the leaf to the root must be computed for the first packet received, but the 
verification of subsequent packets can be optimized by re-using hash values that 

10 were previously computed, verified and then cached. The next received packet 

P(i+1) is verified by hashing it until a node in the cache is reached that was previ- 
ously authenticated. The cache structure suggested by Wong-Lam mimics the 
structure of the original authentication tree at the sender used to compute the sig- 
nature on TG. The receiver then requires a storage of the size 0(n) since this is 

15 the size of the authentication tree. 

Though the described Wong-Lam approach allows verification on-the-fiy and thus 
inherently provides a solution for data packet loss, it requires transmission of a 
substantial amount of verfication data with each packet in addition to the "useful" 
20 data. It also requires a substantial amount of computing at the receiving end. 

Since this can result in a rather poor overall transmission efficiency, the Wong- 
Lam solution may be useful and/or applicable only in certain environments. 

The present invention improves the prior art approaches, in particular the Wong- 
25 Lam approach, by providing a solution that has two advantages over this known 
method. Firsts the present invention needs a significantly lower amount of verifi- 
cation data to be transmitted with each data packet than Wong-Lam. Second, the 
present invention differs in that it lowers the amount of storage required at the 
receiving end without increasing the time for verification at the receiver .Thus, the 
30 general object of the present invention can be said to allow safe transmission 
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between an application or service provider and a portable device having a limited 
storage or memory capacity and/or restricted processing power, such as smartcards 
and the like. A particular object of the present invention is to provide a method 
and an apparatus v/ith a faster and/or simpler, but still secure, transmission proc- 
5 ess than the prior art, in particular by reducing the number or lengths of transmis- 
sions to be executed in an environment where data and/or applications have to be 
transferred securely, and/or limiting the necessary computing and thus providing a 
significant improvement at the receiving end, which is typically a smartcard or 
similar device with the limitations mentioned above. 

10 

A special object is to provide an efficient method in terms of storage and verifica- 
tion time to dowload code blocks from an application provider to a portable 
device such as a smartcard. 

15 A more particular object of the present invention is to increase the efficiency of 
updating code blocks for existing applications of smartcards and similar devices 
with limited memory and/or computing power. 

The Invention 

20 The present invention provides this solution by selecting a novel approach which 
will be called '^Dynamic Tree Authentication" (DTA) in the following. It differs 
from the CASCADE and the Merkle approaches as well as from the Wong-Lam 
approach described above, 

25 Whereas the CASCADE solution creates a linear hash chain, the solution accord- 
ing to the present invention uses an authentication tree to create a "nonlinear** 
hash chain for block update, preferably with a logarithmic length hash path. The 
present invention also intrcxiuces a new method for evaluating the order of the 
nodes in the authentication tree. Particularly this latter approach reduces 
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verification delay from linear time, i.e 0(n) as identified above, to constant time, 
i.e. 0(1), which is the maximum achievable. 

The Merkle approach, as mentioned above, uses the principle of an authentication 
5 tree, but only for a principally static method of providing digital signatures or 

authenticating items. It does not address the peculiarities and dynamics of a trans- 
mission to a receiver with limited memory and/or computing capacity. The inven- 
tion instead focuses on this latter problem and creates a novel transmission pattern 
or scheme, based on a modified authentication tree process. 

10 

The present invention can be seen as an optimization of some ideas presented by 
Wong-Lam for signing digital streams, tailored to the specific problem of applica- 
tion download/update. There are applications wherein a digital stream is sent 
from a sender to a group of receivers, for example a set of subscribers for a video 

15 service, or the participants in a teleconference. The digital stream consists of a 
large amount of data, potentially generated in real time, to be distributed over a 
communication channel that may provide an unreliable delivery service. Further, 
the communication mtay be one-way in the sense that the receivers have no chan- 
nel back to the sender to conform receipt of the stream or identify stream errors. 

20 Or, if a back channel does exist, the bandwidth on this channel is very low. 

Together these characteristics imply that any signature scheme must be suffi- 
ciently robust to handle packet loss and reordering and to support signature gen- 
eration and verification functions that are efficient enough to allow fast delivery of 
the stream. 

25 

The application download problem can be viewed as a digital stream between a 
single sender {the application provider, AP) and a single receiver (the smartcard, 
SC). In this case the receiver is a very constrained device, and the signature veri- 
fication algorithm should not require large amounts of computation or storage. 
30 The channel between the AP and the SC is generally reliable but slow, so that the 
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signed stream should be formatted as efficiently as possible without regard for 
packet loss or reordering. Therefore it is possible to propose a method for signing 
application code blocks that improves a direct application of the Wong-Lam solu- 
tion for digital streanas. 

5 

In some more detail^ the invention is based on the use of an authentication tree to 
amortize the computation of the digital signature over a coUection of code blocks, 
similar to the Wong-Lam approach where the authentication tree is used to amor- 
tize the computation of the digital signature over the packets of a transmission 

10 group. Since packets may be lost or reordered, the Wong-Lam approach appends 
to each packet Pi its hash path in the authentication tree, along with the signature 
on the authentication tree, which permits each packet to be verified independent of 
what other packets from the transmission group are received. The receiver recon- 
structs the original authentication tree of the sender by caching the hash values of 

15 the hash paths for packets that are received. This means that for transmission 

group of n packets, each packet is sent with 0(log n) hashes and a copy of the sig- 
nature on the authentication tree, which will be several thousand bits in length. 
Thus an additional 0(n log n) hashes and 0(n) copies of the signature on the 
authentication tree must be transmitted along with the n packets of the transmis- 

20 sion. Also, the receiver requires 0(n) storage to verify the packets of the trans- 
mission group. So much on Wang-Lam. 

The present invention provides a signature on a collection of n code blocks (which 
can roughly be viewed as a tramission group) based on an authentication tree 

25 where only 0(n) additional hashes and one copy of the signature on the authenti- 
cation tree are required to be transmitted by the sender. This alone distinguishes 
the invention already from Wang-Lam. Further, the receiver need only use 
0(log n) storage to verify the collection of n application code blocks. This pro- 
vides a clear advantage of the present invention over the Wong-Lam approach for 

30 signing digital streams when applied to the application download problem. The 
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improvement over Wong-Lam is derived from taking advantage of the reliable 
channel that is expected to exist between the AP and SC, thus allowing the 
amount of redundant signaling information that would otherwise be sent with the 
code blocks to be reduced. 

To sunmiarize, the present invention can be said to be a solution for verifying a 
code block in the transmission of data and/or applications from a provider to a 
receiver with limited memory and computing power, particular for downloading, 
updating and/or incrementing applications that has the following properties : 
L each code block is verified after an essentially constant delay, 

2. the overhead in terms of additional signature information that must be trans- 
ferred with the code blocks to obtain the constant delay is linear in the number 
of code blocks, 

3. the amount of memory required by the receiver to verify each received code 
block is logarithmic in the number of blocks, and 

4. an individual code block can be updated with a logarithmic transmission cost, 
and a logarithmic cost for verfication and memory at the receiver. 

While other solutions satisfy some of these properties, the present invention is 
novel in that it satifies all properties. Thus, Dynamic Tree Authentication (DTA) 
offers a good tradeoff between delay and memory as each of the main parameters 
is either a logarithmic function of the number of blocks n to be downloaded, or is 
independent of This is a clear advantage and improvement over known meth- 
ods which normally require either 0(n) for the memory or verification delay in 
one or both of code block downloading and updating. 

In other words, whereas the application of an authentication tree to the down- 
load/update/increment code block problem results in detecting if an error has 
occurred but not the location of which block(s) are incorrect, DTA, i.e. the 
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Dynamic Tree Authentication according to the present invention, allows to iden- 
tify in which block one or more errors are located. 



Description of an Embodiment 
5 In the following, the aspect of the application of an authentication tree structure to 
the download/update/increment code block problem when transmitting to smart- 
cards and the like and the Dynamic Tree Authentication method (DTA) will be 
discussed in more detail, taking a protocol between a smartcard (SC) and an appli- 
cation provider (AP) as example. It is assumed that the SC has AP's public key 
10 and can thus check signatures on data produced by the AP. 



Apart from pseudocode listings within the text, this description is supported and 
completed by the appended drawings which illustrate in: 



15 Fig, 1 an authentication tree for n = 8; 

Fig, 2 a table for the storage required to verify a tree authentication for r = 8; 

Fig, 3 a table for the storage requirements for DTA for « = 8; 

Fig. 4 a summary of time and storage requirements for code block download 
and update; 

20 Fig. 5 a functional example for an application provider (AP); 

Fig. 6 a functional example for a smartcard (SC); 

Fig. 7 the control flow for the download of an application at the AP; 

Fig. 8 the control flow for the download of an application at the SC; 

Fig. 9 the control flow for the updating of an application at the AP; and 

25 Fig, 10 the control flow for the updating of an application at the SC, 



Download Protocol from CASCADE: Several protocols for the secure download 
and update of SC applications were developed for CASCADE, an ESPRIT 
project, described under http://diceMcLac.be/crypto/cascade/cciscadeMtml in the 
30 Internet, as mentioned above. They are also documented in J.-F. Dhem: "Design 



- 12- 



of an Efficient Public Key Library for RISC-based Smart Cards", PhD Thesis, 
Catholic University Lou vain, 1998. 

Be it assumed that the code to be downloaded is partitioned into code blocks fil, 
5 B2, ... , Bn, and that /ef*; is a hashing function such as SHA-1. The prior art 

solution is to link the blocks through the hash function such that the correctness of 
each block can be verified on-the-fly and further, there is a hash value that is a 
function of all received blocks. For n blocks, a hash vector H = (HI, H2, .„ , 
H(n^l)) of f/i+i) components is produced as shown below. 

10 

H(n -h 1) random value 

for i n downto 1 do 

Hi - h(H(i + l)\\Bi) 

od 

15 wherein /z is a hashing function such as SHA-1 
H(n 4- 1) is the hash of a random value 
II denotes concatenation 
^ means assignment of right to left. 

20 Note on H(n'hl): the hashing process to produce the Hi is based on the current 
block Bi and the hash of the previously hashed block B(i^l ) as represented by 
H(i-^l). This process is not defined for the block Bn since there is no block 
B(n-¥l) that was hashed before it. So we simply start the process by assiging a 
random value to fff/i-fi) so that Bn can be hashed to give Hn, and the same hash- 

25 ing process can be used for all blocks. 

The above process generates hash values for secure download using a kind of 
chained hashing. The AP signs HI, and then sends the following (« + 2) mes- 
sages to the SC: 



30 
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Sign(Hl), (Hl.Bl), (H2,B2), ... , (Hn, Bn), H(n-hl). 

The SC first verifies the signature on HI and then proceeds to verify the hash 
chain used to form the hash vector. Due to the form of fiie chain defined above, 
5 each application block Bi can be verified after the next 2-tuple (H(i'¥2), B(M)) 
has been received, which in the terminology defined means a maximum verifica- 
tion delay of one block. If a code block Bi is to be updated, then the hash chain 
must be recomputed from position / forward due to the linear nature of the hash 
chain. This scheme will be referred to as "CASCADE with hashes". 

10 

As noted by J.F. Dhem, supra, the n hash values Hl^ H2, ^ Hn need not be sent 
by the AP, since these values can be generated by the SC. This scheme will be 
called "CASCADE without hashes''. The penalty for this reduced transmission is, 
however^ that the code block verification cannot begin until H(n + 1) has been 
15 received, meaning that the maximum block delay before verification is 0(n) when 
no hashes are sent. Regardless of whether the hashes are sent at the time of down- 
load, they have been discarded by the time of update. Thus, this scheme also has 
an 0(n) update time for a code block. 

20 Using Authentication Trees: An authentication tree is a data structure used to 
authenticate information Al, A2, ... , An. The basic idea is to select a labelled 
binary tree T with n-2^ leaves and to associate Ai with the t-th leaf. The tree 
will have depth d, where the root is at depth 0 and there are 2' nodes at level /. 
The tree T has exactly n leaves associated with the values of Ai, A2, An and 

25 exactly n-i internal nodes with two children each. 

It now remains to compute the hash component of the tree. The t-th leaf is 
labelled with H(Ai) — h(Ai) where Ai is associated with the leaf. Then, beginning 
at depth d and proceeding to the root at depth 0, each internal node j is labelled 
30 with Hj = h(H(L) II H(R)), where H(L) and H(R) are the labels of the left and 
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right children, respectively, of node j. The label at the root, denoted H(T% is a 
hash value that depends on Al, A2, An. 

As shown and explained further down in connection with Fig. 1, the AP can use 
an authentication tree to authenticate a set of n code blocks Bl, B2, Bn sent to 
the SC. The AP signs H(T), then sends H(T), its signature and the code blocks 
Bl^ B2, Bn, Note that no block can be rejected as unauthentic until all blocks 
have been received, since the locally computed value of H(T) is not available 
until that time. Further, if the generated root hash does not match the received 
root hash then the incorrect block(s) cannot be identified and all blocks must be 
retransmitted. Thus, the verification delay for basic tree authentication is 0(n). 
By forming the hashes for the leaves at level d, and then the hash values at level 
d-1 and so on towards to root, the verification of T will also require a memory of 
the size 0(n), However it is possible to use another recursive method with the 
property that verification will only require a memory "cost" of (log n^l), which 
is O(log n). 

An advantage of tree authentication over other methods such as linear hashing is 
that an individual block can be updated in a logarithmic number of messages (or 
by a single message with a logarithmic number of components). To update Bi to 
Bi\ the AP first associates the i-th leaf with BV and then recomputes the hash val- 
ues of the tree to give the new root value H'(T). The AP then signs the new root 
value H'(T) and then sends H'(T), its signature, and Bi\ The SC then recomputes 
the hash tree of the code blocks it has after replacing Bi with Bi\ and verifies that 
the newly computed root hash equals the received value of H'(T), If the hashes 
agree, and the signature is correct, then Bi is updated as Bi\ Thus, using tree 
authentication, n code biocics can be downloaded in time 0(n) using 0(log n) 
memory, and a block can be updated in 0(log n) time and with 0(log n) memory. 
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The Wong-Lam Solution: It is possible to consider Bl, B2, Bn as one transmis- 
sion group in a digital stream, and then apply the Wong-Lam solution for signing 
each transmission group that comprises a digital stream. At the sender, the code 
blocks Bi are arranged into an authentication tree as described above, and the tree 
5 is signed by computing its hash. Let Sign(HT) denote the signature on the hash of 
the authentication tree for the code blocks. To avoid 0(n) delay at a receiver, 
when Bi is to be transmitted, the sender transmits not only Bi^ but also its path in 
the authentication tree and the signature Sign(HT), Referring to Fig, 1, when BI 
is to be sent, the sender actually sends (BI, H(B2), H(2), H(6% Sign(HT)), With 

10 the hash values H(B2), H(2), H(6) it is clear that the receiver can form the hash 
path from the leaf for BI to the root of T and then verify the received code block 
for BI against the received signature Sign(HT) value. Similarly when B5 is to be 
sent, the sender transmits (B5, H(B6), H(4), H(5), Sign(HT)), and the hashes 
H(B6), H(4), H(5) allow the received code block B5 to be verified. It is clear that 

15 the verifications of BI and B5 are essentially independent in that each code block 
is sent with sufficient information to perform verification independent of what 
other information is sent for the transmission group in this the set of code blocks. 
In particular, the order in which the code blocks are received does not affect their 
verifiability (the receiver may receive BI and then B5^ or B5 and then Bl)^ and 

20 code blocks may also be lost (B5 can still be verified if BI is lost in transmission). 

When verifying a received packet Bi^ the whole hash path from the leaf for Bi to 
the root need not necessarily be recomputed, since the receiver may reuse hash 
values that were computed during the verification of previously received packets. 
25 For example, consider sending (BI, H(B2), H(2), H(6), Sign(HT)) and (B2, 
H(BI), H(2), H(6), Sign(HT)) for code blocks BI and B2. Assuming that the 
code blocks are received in the order BI and then and further that BI is veri- 
fied, then in order to verify B2 the receiver need only recompute the hash of B2 
and compare it with the hash value H(B2) associated with BL The verification of 
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B2 is simplified because its hash path has several hash values in common with the 
hash path of Bl, 

In general, the receiver will maintain a cache of hash values that have been veri- 
5 fied against the signature in the root hash of the authentication tree. In the exam- 
ple above, if the message (Bl, H(B2), H(2), H(6), Sign(HT)) was received, then 
from Fig.l the computation of the hash path for Bl would involve the seven hash 
values H(B1), H(B2% H(l), H(2), H(5), H(6), and H(T). Jf H(T) is verified with 
the signature Sign(HT), then H(Bl)y H(B2), H(l), H(2), H(5), H(6) and H(T) 

10 could also be verified and cached. The hash path for the next block would need 
only be evaluated until it recomputed one of the cached hash values. A compari- 
son between the computed and cached hash value is made, and if the computed 
and cached hash value are equal, the block is defined to be verified. In the exam- 
ple above if (B2, H(B1), H(2), H(6), Sign(H(T)) was received after (Bl, H(B2), 

15 H(2), H(6), Sign(H(T)) and H(B1), H(B2), H(l), H(2), H(5), H(6) and H(T) 
were cached, then the first computation in the hash path of B2 is H(B2) which 
could immediately be compared against the cached value of H(B2), 

Any hash values generated in the verification of Bi that have not been generated 
20 during the verification of any previouly received code blocks are added to the 

cache. If the cache is arranged as a tree» similar to the original authentication tree 
at the sender, a code block Bi will be verified by generating its hash path from the 
leaf representing Bi to the hash of the least ancestor of Bi that has been previously 
verified (and hence cached). The first code block received arrives when the cache 
25 is empty but it can always be verified since all the hash values required to com- 
pute its hash path are included in the message for the block, including the signa- 
ture on the root. 

From the discussion above it is clear that the Wong-Lam solution, as applied to 
30 signing code blocks, has 0(1) delay for verification. However, the memory 
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requirements at the receiver are 0(n), since if ail n code blcx:ks are received and 
verified then 0(n) hash values will be cached. No hash values are ever deleted 
from the cache in the Wong-Lam solution. 

5 But we observe that if Hi is a hash value in the authentication tree, with H(L) and 
H(R) its left and right children respectively, then Hi need not be cached when 
H(L) and H(R) are cached since any hash path that involves Hi will be verified by 
either H(L) or H(R). However, even with this optimization the worst case mem- 
ory is still 0(n) given that packets may be reordered. 

10 

The Present Invention, le. the DTA Solution: The method according to the inven- 
tion, called Dynamic Tree Authentication (DTA), is also based on authentication 
trees and retains the logarithmic time for block update and also gives a 0(1} veri- 
fication delay. It is generally apphcable for code block authenticating as well as 
15 for the download/update/increment code block problem, but not restricted to that 
This is achieved by sending a particular sequence of hash labels of the internal 
nodes of the authentication tree along with the code blocks to be authenticated, 
thus allowing verification of intemal nodes of the tree besides the root 

20 The DTA invention embodiment will be specified by giving the description of two 
processes, which will be called SendBlocks( ) and ReceiveBlocks( )- Assume 
that the n code blocks Bl, B2^ Bn are to be downloaded from an AP, an appli- 
cation provider, to an SC, a smart card. The SendBlocks( ) process is executed at 
the AP to create the messages to be sent from the AP to the SC that constitute the 

25 downloading process. The SC uses the ReceiveBlocks( ) process to receive the 
messages from AP and to verify the code blocks based on the information in the 
messages. Descriptions of the SendBlocks( ) and ReceiveBlocksC ) processes 
follow. 
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The SendBl0cks( ) process shall be described first in connection with the pseudo- 
code listing A (Listing A) below. As with the other processes to be described as 
part of the present invention, the SendBlocks{ ) process is mainly concerned with 
accessing the hash values encoded in the authentication tree for the code blocks. 
5 For this reason, the steps of the process as described in Listing A are expressed in 
terms of standard operations on a computer representation of a logical tree. For 
more details see A. Aho, J. Hopcroft, J, UUman, *The Design and Analysis of 
Computer Algorithms'% Addison-Wesley Publishing Company, 1974. 

10 The basic data structure that will be used in SendBlocks( ) is the concept of a 

"nod€'\ In this desdription, a node has the following attributes: a parent node, a 
left child node, a right child node, a hash value, and a field that indicates if the 
hash value for the node has been previously sent with a code block. These fields 
for a given node node are accessed as follows: 
1 5 parenti node) gives the parent of node^ 

nodeJeft gives the left child of node, 
nodcright gives the right child of node, 
node, hash is the hash value of node, and finally 

nodeMashsent is true if the hash value for node has been previously sent and is 
20 false otherwise. 

We also assume that leaf nodes have no children, and the root of the tree has no 
parent. The root value is a node distinguished by the name root^ and rooLhash 
denotes the hash of the authentication tree. Since by construction the leaf nodes 
25 of the authentication tree correspond to code blocks, we also let node(Bi) denote 
the leaf node corresponding to BL 

With this notation, we now describe the SendBlocks( ) process as shown in List- 
ing A. This routine will be run by the AP that wishes to send the code blocks Bl, 
30 B2f Bn to the SC. Each code block Bi will be sent in a message M/, where Mi 
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will contain Bi and possibly some additional hash values from the authentication 
tree for BJ, B2, Bn to facilitate verification at the SC with low delay and 
memory overhead. 

5 Listing A 

1 . SendBIocks( Bi, B2, , Bn ) 



/* generate and sign authentication tree, send signature */ 

10 2, T ^ authentication tree for Bl, B2, „„ , Bn ; 

3 . Sign (H(T)) ^ AP signature on HT ; 

4. send{Sign(HT))\ 

/* generate message blocks */ 

15 5, for i from 1 to do 

6. Mi ^ Bi ; 

7. ptr node( Bi )i 

8. while (/?rr <> root )^nd {ptr.parent.right.hashsent = false) do 

9. Mi ^ ( Mi IS ptr, parentsighthash ) ; 
20 10, ptr par en t. right, hashsent — true; 

1 1 . ptr *- parent( ptr ) ; 

12. od; /-while*/ 

13. send(M/) 

14. od; /*for*/ 

25 15, end; /* SendBlocks */ 



When the SendBlocks( ) process is executed, all n code blocks are passed as 
inputs. The authentication tree for BI, B2, Bn is constructed and hashed (steps 
2 to 3), with the resulting signature Sign(HT) sent to the SC (step 4). The 
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messages corresponding to the code blocks that will be used to verify this signa- 
ture are now created* 

SendBIocks( ) has a main for loop (steps 5 to 14) that executes n times and proc- 
5 esses the /-th block Bi at the i-Xh iteration. The outcome of the /-th iteration of the 
main loop of SendBlocks( ) is the construction of the /-th message Mi that is sent 
to the receiver at step 13. Mi is initialized to Bi and then further processing (from 
steps 7 to 12) adds any additional hash values to Mi that will be required at the SC 
to perform the verification of Bi after it is received, 

10 

We now explain how the additional hashes for 5/ are determined by the Send- 
Blocks( ) process from steps 7 to 12. At step 7, a temporary value ptr is assigned 
to node(Bi), the leaf node corresponding to Bi. The while loop from steps 8 to 12 
traces the path from node(Bi) to the root node of the authentication tree by 

15 repeatedly assigning ptr to its parent (step 11). At each new node referenced by 
ptr, if the hash value of the right brother node has not been sent as part of a 
previous message then this hash value is appended to Mi. Equivalently if 
ptr.parenLright.hashsent is false, then ptr, parent.righLhash is appended to Mi at 
step 9, and ptr, parent, right, hashsent is set to true to indicate that this hash value 

20 need not be sent with any ftiture message. This process of appending hash values 
to Mi continues in the while loop until either the root is reached or ptr references 
a node for which the hash of its right brother was sent by a previous message. At 
this point, the message Mi for code block Bi is complete and can be sent to the 
SC. The creation of the next message M(i^J) for the code block B(i^l) begins at 

25 the (i+l)'St iteration of the main loop of SendBlocks( ). The main loop continues 
in this manner until all n messages for all n code blocks have been generated and 
sent, at which point SendBlocks( ) exits. 

As an example, consider executing SettdBlacks( ) on the authentication tree of 
30 Fig. 1 with the call SendBlocks( BI, B2, B8 ). After the signature on HT has 
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been sent, the contents of the eight messages Ml, M2, M8 corresponding to the 
code blocks Bl, B2, B8 are 



Ml 




{ 


Bl, H(B2}, H2, H6 ], 


M2 




{ 


B2 }, 


M3 




{ 


B3, H(B4) }, 


M4 




{ 


B4 }, 


MS 




{ 


B5, H(B6), H4 ), 


M6 




{ 


B6 }, 


M7 




{ 


B7, H(B8) ], 


M8 




{ 


B8 ]. 



We make several observations about the message blocks. First, the message 
blocks for even indexed code blocks - in this case M2^ M^, - consist 

1 5 simply of the corresponding code block- This is because H(B(2i)) is required to 
verify H(B(2i-l)), Second, the longest message is Ml, since at the time Ml is 
constructed no hash values have been sent, and Ml then includes the full hash 
path for Bl. In general, no message block Mi produced by SendBlock$( ) will 
require more than d additional hashes to be sent v^ith the code block Bi when 

20 n = 2^. Third, we see that each of the hash values sent with a message are the hash 
values of right children of nodes in the authentication tree. Since there are n-i 
intemai nodes in an authentication tree with n leaves, Send©locks( ) will generate 
less than n/2 hash values to be sent with the n messages Ml, M2, Mn associ- 
ated with Bl, B2, Bn, So much on the SendBlocks( ) process . 

25 

Now follows the description of the ReceiveBlocks( > process. Using this process, 
the SC processes the signature and messages it receives from the AP; the process 
is shown in Listing B further down. 
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The ReceiveBlocks{ ) process maintains the global data structure cache^ which is 
an array of hash values* The fields of cache can be addressed from 0 up to d, the 
depth of T. For each level i of the authentication tree T, field cacke[i'\ holds hash 
value/l(/) of a node that has been verified last in the processing of a previous 
5 message. 

In the setup phase (steps 2-5 of Listing B\ the ReceiveBIocks( ) process first 
reads and verifies the signature Sign(HT) on the authentication tree extracts the 
hash value HT of the root, and then stores the hash HT of the authentication tree 
10 in field cacte[^]. 

ReceiveBlocks{ ) has a main for loop (steps 6 - 20) that executes n times and 
receives and verifies the /-th code block at the /-th iteration. At the /-th iteration, 
it receives message Mi (step 7), extracts code block Bi out of message Mi (step 8), 

1 5 computes the hash value H(Bi) of that code block and stores the computed hash 
value in the temporary variable h (step 9). Next, ReceiveBlocks( ) computes the 
hash values of intermediate nodes in the authentication tree until it reaches a node 
which has already been verified in the processing of a previous message (steps 10 
- 1 5). For each not yet verified node, ReceiveBIocksC ) extracts the hash value of 

20 its right brother from the received message Mi and stores the value in the corre- 
sponding field of the cache (step 12), computes the hash value of the parent node 
and stores it in temporary variable h (step 13). Finally, the routine compares the 
computed hash value stored in variable h vrith the hash value of the already veri- 
fied intermediate node (step 16). If the values are equal, block Bi is considered 

25 verified and ReceiveBlock$( ) clears the hash value of the already verified inter- 
mediate node in the cache (step 17). Otherwise, ReceiveBlocks( ) indicates an 
error (step 1 8). The main loop continues in this manner until all n messages for 
all n blocks have been received and verified, at which point ReceiveBlocks( ) 
exists. 



30 
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Listing B 

1 . ReceiveBl0cks(«) 

5 2. depth = d\ 

3. cache[ 0 depthY, /* global array of hash values */ 

/* read authentication tree signature */ 



4. sig ^ read (Sign(HT)) ; 
10 /* read messages and verify code blocks */ 





6. 


for i from 1 to « do 




7. 


Mi *- read( ) ; 




8. 


Bi code block from Mr ; 




9. 


// *- H(Bi) ; 


15 


10. 


j *- depth ; 




11. 


while (y > 0 ) and ( cacheO] = 0 ) do 




12. 


cachelf] *- head( Mi) ; 




13. 


h^H(,h\\ cache\j]); 




14. 




20 


15. 


od; /* while */ 




16. 


if €ache\]\ =^ h 




17. 


then cache\j] 0; 




18. 


else error 




19. 


fi 


25 


20. 


od; /* for */ 




21. 


end; /* ReceiveBlocks */ 
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As an example, consider executing ReceiveBlocks( ) on the authentication tree of 
Fig. L After the signature on HT has been verified, field cachei\\ holds HT. All 
other fields are empty. Next, ReceiveBlocks( ) receives the first message: 
Ml ^ { Bl, H(B2), H2, H6 } 
5 As the fields cache[4]y cache[3], and cache[2] are empty, the while loop (steps 1 1 
- 15) will extract the three hash values H(B2), H2, and H6 from the message. 
These hash values form the full hash path for Bl and allow to compute and verify 
node HT, As a side effect, nodes H(B2), H2y and H6 are also verified and thus 
stored in the cache. As nod^HTis verified, field cachel\\ is cleared. 

10 

Let us assume that flie next message received contains an even indexed code 
block. Then the previous message contained the code block's hash value and got 
stored in field cache[4]. Thus, the even indexed code block can be immediately 
verified and field cache[4] will be cleared. In general, whenever a node is verified, 
15 the corresponding field in the cache is cleared (step 17). 

Finally, let us consider the case when the next message received contains an odd 
indexed code block B(2J-hl), We know from above that the previous iteration 
(iteration 2j) of the for loop cleared field cache[4] and thus at least the hash value 

20 of the next code block B(2j'^2) wiU be extracted from the message. If the parent 
node ha^ not been verified previously, the hash value of the parent's right child 
will be extracted from the message. Note that intermediate nodes get verified 
before their right child got verified. Thus, walking up towards the root until an 
already verified node is reached, the least hash path to verify the code block is 

25 obtained. 



An example for an authentication tree with n = 8 is shown in Fig. 1. The storage 
requirements for a straightforward process for transmitting data and/or applica- 
tions from an AP to an SC according to the invention are shown in Fig. 2, whereas 
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the DTA scheme according to a further improvement of the invention is shown in 
Fig. 3. 

Fig. 1 shows the hash tree that results from authenticating the 8 blocks Bl, B2, 
5 B8. The blocks are first grouped in pairs, then hashed to give HI, H2, H3, H4, 
then paired again and hashed to give H5, H6. One more hash is used to compute 
the root hash H(T). It should be observed that the hash of the blocks is computed 
"bottom up", meaning that hashing begins at the leaves, here the blocks Bl, B2, 
B8, and further hash values are computed as one proceeds towards the root In 
10 another way, one sees that the tree has a total depth of 3, where H5 and H6 are at 
depth 1, and HI, H4 are at depth 2, and the Bi are at depth 3, By convention 
the root is usually assumed to be at depth 0. The hashing process begins at depth 
3, goes to depth 2, then depth 1, finally producing the root value at depth 0, 

15 In a simple process, the AP signs H(T) and sends Bl, B2, B8, Sign(H(T)) to 
the SC for verification. It is assumed that the SC receives the blocks in the order 
Bi, then B2, and so on until B8, and then the signature Sign(H(T)). To verify the 
signature on the blocks, the SC must repeat all the hashing computations shown in 
Fig. 1, so that the correct value of H(T) is found. 

20 

Fig. 2 shows the computation and storage required by the SC as each block Bi is 
received. For example, when the first block BI is received, it is hashed and this 
hash value H(B1) is stored. When B2 arrives, it is also hashed to result in H(B2), 
which is then hashed with H(B1) to give HI, This value HI must be stored for 
25 the later computation of £r5. The various colums of the table in Fig, 2 show 
which hash values must be computed and stored for later use. 

It is obvious from the above description that the described straightforward process 
results in the authentic and i^liable transmission and/or update of data between a 
30 AP and a SC, but that it also has two disadvantages. These are the late availability 
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of any final authentication results and the necessity to calculate the complete hash 
tree whenever an error is detected 

Now, for the improvement of the invention, namely the application of the DTA 
5 scheme. Fig. 3 shows an example of the messages sent from the AP to the SC for 
/I = 8 code blocks. Thus, the authentication tree of Fig, 1 still applies. The first 
few rows of in Fig. 3 shall be explained in detail. Initially, the AP sends the sig- 
nature Sign(HT). SC validates the signature and stores value HT. Next, AP 
sends message {B1,H(B2),H2,H6}. With this information, root value HT can be 

10 calculated (HI = h(h(Si)llff(B2), H5 = h(Him2\ and HT' = h(H5m6)) by the 
SC. If the calculated value HT^ is equal to the value HT contained in the signa- 
ture, code block Bl is verified. As a side effect, also values H(B2)y H2^ and H6 
are verified and therefore stored in the SC hash storage. The AP next sends mes- 
sage {B2}. Now, the SC can immediately verify block B2, since it can compute its 

15 hash value H(B2) and compare it with the stored value of H(B2) as received in the 
previous message. Value Jtf(jB2) is removed from the hash storage. Message 
{B3,H(B4)} follows next. SC computes the hash value H(B3) of the code block 
and the hash value of the parent node H2 = h(H(B3)\\H(B4)). As the parent node 
H2 is akeady in the hash storage, SC can compare both values to verify code 

20 block B3, If equal, SC removes H2 from the cache but includes the newly 
received hash value H(B4), 

The table shows which leaves and internal nodes are verified as each new mes- 
sage is received at the SC. Note that the storage needed for the intermediate hash 
25 values has the size 0(log n). 

The table in Fig. 4 compares the DTA solution according to the present invention 
with the CASCADE and T A (tree authentication) approach and clearly shows the 
advantage of DTA over the prior art. 

30 



-27- 



. Incremental code blocks: It may also be the case that a given application of n 
blocks Bly B2, ,„ , Bn is to be increased to have n^l blocks with the addition of 
a new code block B(i -hi). Adding a new code block can be considered as a spe- 
cial update operation in DTA, Let H(T) be the DTA authentication tree for the 
5 code blocks Bl, B2, , Bn, which will consist of a binary tree with internal nodes 
and leaves, where each internal node will have two children (excluding the case of 
n = i). Each leaf is a code block Bi, and is positioned at some depth d in H(T), 
To add a new code block B(n -h i) to H(T), one considers the set of leaves that are 
at the mimimum depth d in H(T)y and pick one at random, here denoted as Bi. 
10 Then the node for Bi is replaced by an internal node that has Bi and Bfn i) as its 
children. 

To add the new code B(i -hi) block to those existing in the SC, the AP adds 
B(n + 1) to the H(T) as described above and then computes the new root value 

15 W(T}. Then, the AP sends W(T), its signature Sign (HT'), the index i and 

B(n -k- 1) to the SC, where i indicates the leaf in the current authentication tree that 
will become the parent of the new code block. The SC mserts B(n-^l) into the 
authentication tree, recomputes the hash tree and verifies that the newly computed 
root hash equals the received value of H'(T). If the hashes agree, and the signa- 

20 ture is correct, then B(n I)is added to the code blocks. The above protocol 
naturally extends to the case where m new blocks are added. 

Fig. 5 shows the main elements of an embodiment of the Application Provider 
(AP). The AP has a environment 1 for developing and updating applications. 

25 Environment 1 consists of various software tools that may include a compiler, i.e. 
a tool for translating an application written in a high level computer language into 
a form suitable for execution on a another computing device, such as a smartcard, 
a profiler for improving code performance, and a debugger for assisting in the 
removal of logical errors from the application. Environment 1 will also have 

30 access to various existing application libraries to perform standard functions such 
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as reading and writing to a file, making a network connection* or opening a win- 
dow on a display. The application development and update environment 1 will be 
embodied as software on a general computing device that has a control unit 7, 
transport circuitry 11, which is usually a network connection, a user input device 
5 8, for example a keyboard, memory 9, and a display device 10. 

The AP uses the application development and update environment 1 to create an 
application. When the development is complete, the result will be application 
code 2 suitable for execution on a class of computing devices. 

10 

Once the application development is completed using the development environ- 
ment 1, which has produced application code 2, the AP can now transmit the 
application code 2 to various devices that will execute the application code. 

15 The application code is now passed to part 6 of the AP which is responsible for 
formatting the application code 2 for transmission to the receiving device. Part 6 
of the AP responsible for formatting the application code 2 for transmission to the 
receiving device consists of a hash tree encoder 3, a signature module 4 and the 
DTA encoder 5. The application code 2 is passed to the DTA encoder 5, which is 

20 an implementation of the SendBIocks( ) process of Listing A . DTA encoder 5 
first uses the hash tree encoder 3 to produce a hash tree for the application code, 
and then passes the hash tree to the signature module 4 for signature. The signa- 
ture is then passed to the transport circuitry 1 1 for transmission to the smartcard, 
SC. If the application code consists of n code blocks Bl, B2, Bn, then DTA 

25 encoder 5 produces n messages Mi^ M2^ M«. As each message Mi is gener- 
ated, it is passed to the transport circuitry 1 1 for transmission to the SC. 

Fig. 6 shows the main elements of an embodiment of a smartcard (SC) that will 
receive the code blocks from the AP, The SC has a environment 12 for receiving 
30 new applications and updating existing applications. Before the SC will accept 
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new or updated (application) code blocks 13 via transport circuitry 1 1 to be writ- 
ten to long term memory 19 (ROM, EPROM and/or RAM), the AP which pro- 
duced the code blocks must be verified. This verification takes place in part 16 
which consists of a signature module 14 and a DTA decoder 15. The messages 13 
5 produced by the AP for the code blocks are passed to DTA decoder 15 which 
implements the ReceiveBlocfcs( ) process of Listing B. DTA decoder 15 uses 
signature module 14 to verify the first code block received. The other received 
code blocks 13 are verified using cached and received hash values as described in 
the RecieveBlocks( ) process of Listing B , If all code blocks are verified, the 
10 code blocks are written to long term memory 19, 

In Fig, 7, the control flow at the AP of Fig. 5 is shown. The application is first 
developed in the application developed environment 1 (Fig. 5) and then formatted 
into code blocks Bl^ B2, Bn. These code blocks are then encoded into a hash 
15 tree using the hash tree encoder 3, The root of the hash tree is signed to give 

Sign(HT) using the signature module 4 and then sent to the smartcard, SC, Each 
code block Bi is then processed according to the SendBlocks( ) process of 
Listing A to produce message Mi, which is sent to the SC. When all ft code 
blocks have been processed then the control flow exits. 

20 

In Fig. 8, the control flow at the SC of Fig. 6 is shown. The SC receives the sig- 
nature Sign(HT) on the code blocks Bl^ B2, Bn and caches the signature for 
the verification of the code blocks to follow. While there a^ more code blocks to 
receive, the SC reads the next message Mi as described in the ReceiveBlocks( ) 

25 process of Listing B and verifies code block Bu The verification of Bi will be 

based on cached hash values and hash values included in Mi. Additional hash val- 
ues generated by the verification process may be cached, according to the 
ReceiveBIocks( ) process of Listing B . If any of the code blocks fail verification, 
then the application download fails; otherwise the verified application is stored on 

30 the smartcard, SC. 
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Figures 9 and 10 describe the control flow at the application provider, AP, and the 
smartcard, SC, for the update of a single code block. In Fig, 9, the application 
provider AP modifies code block in an application that consists of the n code 
5 blocks Bl, B2, Bn, where these code blocks have been previously downloaded 
to and verified by the SC. The AP first recomputes the hash tree for the code 
where the orginal code block Bi is replaced by BH, The root hash HT' for Bl, Bl^ 

B% Bn will be different (with high probability) from the root hash HT for 
Bl, B2, ... , Bi, Bn. The AP signs the new root hash to give Sign(HT^)^ which 

10 is sent to the SC, Next the AP formats a message Mi which will be sent to the SC 
to verify that BH is in fact a new code block for the application currently repre- 
sented by the code blocks Bl^ B2, ... , Bn. The message Mi is initially the updated 
code block JS 7, and the AP then adds the hash path of B'i from the hash tree for 
Bl^ B2y B% Bn to the message Mi. The AP then sends Mi to the SC and 

15 exits. 

In Fig. 10, the first step of application update at the SC is to receive the new sig- 
nature Sign(HT') on the updated application. The SC stores the signature and 
then waits to receive the update message Mi containing the new code block BH 

20 and hash information to verify Sign(HT'). The SC computes the hash path of B'i 
based on the hashes received and other computed hashes, which produces a root 
hash value that is to be compared against the root hash used to compute 
Sign(HT'). If the signature verifies, then the code block is accepted and the appli- 
cation is updated; otherwise the new code block is rejected. It is clear that since 

25 the depth of the hash tree is 0(log n) then the SC will require 0(log n) storage to 
perform the update. 

Figures 9 and 10 only address the case where a single code block is updated, but 
clearly the AP may wish to update multiple code blocks. If there are multiple 
30 code blocks to be updated, then each code block may be updated separately using 
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the flows of Figures 9 and 10. This would require a signature verification for each 
updated code block, which would be costly. However, it is possible to modify the 
SendBlocks( ) and ReceiveBlocks( ) processes to make multiple code block more 
efficient that multiple single code block update. It is clear to a person skilled in 
5 the art how to modify the SendBlocks( ) and the ReceiveBlocks( ) processes to 
support efficient update in such a case. 

The presented new and inventive DTA method for dowloading to and/or updating 
and authenticating data or applications on a portable device has clear advantages, 
10 for the chosen specific example of a smartcard as portable device as well as for 
other applications. To a person skilled in the art, the invention can easily be 
adapted and applied to any problem where complex applications must be down- 
loaded to or updated in a device having constraints in memory, processing speed 
and/or bandwidth or where updating time and/or security play significant roles. 
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